@zookzook do you prefer to discuss here or back at #211?

I'll provide here some initial feedback related to the present implementation.

First off, thanks for taking the time to implement this extra functionality ❤️

Setup

Here's how I set this up on a Livebook:

Mix.install(
  [
    {:csv, "~> 3.0"},
    {:exqlite, "~> 0.13.15"},
    {:kino_db, "~> 0.2.2"},
    {:kino_explorer, "~> 0.1.10"},
    {:kino,
     github: "livebook-dev/kino", ref: "06625859ef367c50169a280ae5fe33cf9a49a8f3", override: true},
    {:mongodb_driver, github: "zookzook/elixir-mongodb-driver", ref: "preserve-order"},
    {:tzdata, "~> 1.1"}
  ],
  config: [
    elixir: [time_zone_database: Tzdata.TimeZoneDatabase],
    mongodb_driver: [decoder: BSON.PreserverOrderDecoder]
  ]
)

Query with explicit projection

And an example query:

Mongo.find(mongo, "Message", %{},
sort: %{_id: -1}, 
limit: 10, 
projection: [_id: 0, from: "$user.name", at: "$created_at", message: "$data"])
# |> Enum.to_list()
|> Enum.map(fn doc -> 
  doc
  |> Map.get(:order)
  |> Enum.map(fn key -> {String.to_atom(key), Map.get(doc, key)} end)
end)

Since I pass a projection using a keyword list, I expect and get back the :order list in the requested order, and all documents have the very same order. Worked great 👍

I know generating atoms dynamically has its perils, but in this case it seems under control and does improve readability of the output: [[foo: "bar"], ...] instead of [[{"foo", "bar"}], ...]

Query without a projection

Next query, without a projection:

Mongo.find(mongo, "Message", %{},
sort: %{_id: -1}, 
limit: 10)
# |> Enum.to_list()
|> Enum.map(fn doc -> 
  doc
  |> Map.get(:order)
  |> Enum.map(fn key -> {String.to_atom(key), Map.get(doc, key)} end)
end)

The query above represents better what I was originally looking for: exploring a collection and getting the fields in the order that MongoDB has them stored.

This query reviewed an obvious shortcoming of my code to transform the result: it should be applied recursively to handle subdocuments.

This got me thinking maybe I could write a custom decoder that handles recursion while parsing the response from Mongo, and such that I don't need to post-process query results. @zookzook what do you think?

This got me thinking maybe I could write a custom decoder that handles recursion while parsing the response from Mongo, and such that I don't need to post-process query results. @zookzook what do you think?

Keep in mind, that the result of the decoder is used by the driver. If you would change the result by converting the binaries into atoms the whole driver will not work anymore.

Try to use the collection or write just a little recursive function that converts the data into the desired format.

This got me thinking maybe I could write a custom decoder that handles recursion while parsing the response from Mongo, and such that I don't need to post-process query results. @zookzook what do you think?

Keep in mind, that the result of the decoder is used by the driver. If you would change the result by converting the binaries into atoms the whole driver will not work anymore.

I'm not sure I fully understand the implications. Could you give me a code example (perhaps a link to library source on GitHub) where this is happening?

Try to use the collection or write just a little recursive function that converts the data into the desired format.

I read https://hexdocs.pm/mongodb_driver/1.1.0/Mongo.Collection.html, and understood that to use Mongo.Collection effectively I'd need to declare all fields of my documents upfront, for every collection, defeating the idea of reading and printing the documents from Mongo the way (order of fields) they are.

I'll try the recursive function.

I'm not sure I fully understand the implications. Could you give me a code example (perhaps a link to library source on GitHub) where this is happening?

Check this module:
https://github.com/zookzook/elixir-mongodb-driver/blob/master/lib/mongo/stream.ex

I'm not sure I fully understand the implications. Could you give me a code example (perhaps a link to library source on GitHub) where this is happening?

Check this module: https://github.com/zookzook/elixir-mongodb-driver/blob/master/lib/mongo/stream.ex

Is it that exec_command_session returns a "document" that gets decoded the same way that a document within a cursor gets decoded?

From the Mongo.Stream perspective, I couldn't find where the cursor docs are expected to be maps 😕
Looks like docs is an "untouched" list of anything.

Then looking at

I could guess that DBConnection.execute is the thing that eventually returns "doc", but couldn't find where BSON.Decoder is used in the flow going from a query to MongoDB.... I need to fill in some knowledge gaps :)

(...)

I did find https://github.com/zookzook/elixir-mongodb-driver/blob/preserve-order/lib/mongo/messages.ex, so the "messages from Mongo server" are treated the same as the documents within a query cursor, is that right?

So if the result of running a command would not be represented as a map, then the library would error out trying to access map keys or doing pattern matching.

In the meantime, I wrote the recursive function:

defmodule Mongo.Document do
  def to_list(doc, order_key \\ :order) when is_map(doc) and not is_struct(doc) do
    doc
    |> Map.pop(order_key, [])
    |> then(fn {order, doc} ->
      doc
      |> Map.to_list()
      |> Enum.sort_by(fn {key, _} -> Enum.find_index(order, &(&1 == key)) end)
    end)
    |> Enum.map(fn
      {key, value} when is_map(value) and not is_struct(value) -> {key, to_list(value, order_key)}
      {key, value} -> {key, value}
    end)
  end
end

That could help me (or someone else in the future) go from the proposed map + :order key to an ordered collection:

Mongo.find(mongo, "Message", %{},
  sort: %{_id: -1},
  limit: 10
)
|> Enum.map(&Mongo.Document.to_list/1)

From the Mongo.Stream perspective, I couldn't find where the cursor docs are expected to be maps 😕
Looks like docs is an "untouched" list of anything.

No, there are a lot of pattern matches:

 with {:ok, %{"cursorsAlive" => [], "cursorsNotFound" => [], "cursorsUnknown" => [], "ok" => ok}} when ok == 1 <- Mongo.exec_command_session(session, cmd, stream.opts) do
        :ok
      end

I did find https://github.com/zookzook/elixir-mongodb-driver/blob/preserve-order/lib/mongo/messages.ex, so the "messages from Mongo server" are treated the same as the documents within a query cursor, is that right?

Yes, the response is like a wrapper document that contains the "real" documents.

So if the result of running a command would not be represented as a map, then the library would error out trying to access map keys or doing pattern matching.

Yes, that's right!

What about:

  def to_list(doc, order_key \\ :order) do
    doc
    |> Map.get(order_key, [])
    |> Enum.map(fn key -> {key, Map.get(doc, key)} end)
    |> Enum.map(fn {key, value} -> {key, eval(value, order_key)} end)
  end

  defp eval(%{__struct__: _other} = elem, _order_key) do
    elem
  end

  defp eval(doc, order_key) when is_map(doc) do
    to_list(doc, order_key)
  end

  defp eval(xs, order_key) when is_list(xs) do
    Enum.map(xs, fn elem -> eval(elem, order_key) end)
  end

  defp eval(elem, _order_key) do
    elem
  end

the find-index-function may result in a bottleneck.

What about: (...) the find-index-function may result in a bottleneck.

Nice! I didn't consider performance. For my current needs it doesn't really matter. I'm running one-off queries on Livebook :)

Your version reads much better than mine.

Neither of us wrote tests, though 😊! I did manual-test with a few queries -- and while handling the ObjectId struct case I realized that depending on configuration, the :order key may or may not be present.

I think your to_list would return an empty list when the order_key is missing? One extra branching there to handle the case of a missing order_key might do it.

Perhaps we should rename the default name :order to :__order__ to protect it from collisions.

Hey, I still have this in mind, just bandwidth has been limited :)

Mapping out our next steps here:

• rename the default name :order to :__order__ to protect it from collisions
• public documentation for decoders @rhcarvalho (update: the modules have only internal documentation, their existence if however documented in the README)
• provide in documentation an example function mapping "maps with order field" to ordered lists (based on what we've already wrote in previous comments) @rhcarvalho
• remove or document benchmarks (?)
• anything else I missed? Feel free to edit.

By the way, today I learned about String.to_existing_atom through https://erlef.github.io/security-wg/web_app_security_best_practices_beam/common_web_application_vulnerabilities#atom-exhaustion, so that could be used in any example we may end up writing.

I've solved the merge conflict in a local branch and I'm writing docs.

Wanted an opinion regarding configuring an alternative key instead of :__order__.

I thought exposing BSON.DecoderGenerator in docs might be premature/unnecessary, and we'd have more flexibility changing or removing it in future versions if it was kept as an implementation detail for now. I think less concepts also makes the driver easier to use.

What do you think of

1. Use default :__order__

config :mongodb_driver,
  decoder: BSON.OrderPreservingDecoder

2. Set custom key

config :mongodb_driver,
  decoder: {BSON.OrderPreservingDecoder, key: :original_order}

I also briefly considered not introducing BSON.OrderPreservingDecoder at all, but just some driver-level config or config to the default decoder, but didn't quite like it after all... choosing good names is always hard :)

Ah, worth contrasting the above suggestion with what we have currently:

If you want to change the :order key then define a new decoder module:

defmodule MyPreserverOrderDecoder do
  @moduledoc false

  use BSON.DecoderGenerator, preserve_order: :the_key_order
end

(and on top of creating a module, one would still need to update the config too!)

(I was reading a blog post looking for inspiration...)

A disadvantage of setting the decoder globally is that we cannot choose to open two connections with different behaviors, they are forced to use a single decoder implementation.

In tests we can still test each decoder module independently, that's okay -- I wrote some basic tests for each of the implementations we have, with and without order.

@zookzook what if we make the decoder configurable per connection? Apparently it would require wiring things together in Mongo, Mongo.Messages and Mongo.MongoDBConnection.